Adaptive client/server control protocol

ABSTRACT

In various embodiments of the present invention, tiered command-propagation methods are employed within client computers to ensure that monitoring-and-management-related commands are reliably propagated from server computers to client computers. When possible, command propagation is initiated by server computers through a notification process. When the notification process is inoperable, client computers poll one or more monitoring-and-management server computer for commands. When a failed or interrupted notification process is subsequently restored to operability, client computers automatically discontinue command polling and resume relying on server notification for command propagation.

TECHNICAL FIELD

The present invention is related to communications protocols andserver-based management of client computers and, in particular, to anadaptive control protocol that facilitates automatic, continuousmanagement, by one or more server computers, of client computersinterconnected with the one or more server computers through theadaptive client/server control protocol.

BACKGROUND OF THE INVENTION

As the costs of computer systems have continued to decrease, while thecapabilities of computer systems have increased at remarkable rates,personal computers and work stations have become ubiquitous in office,manufacturing, education, and home environments. As the number ofpersonal computers and workstations used in these environments hasincreased, monitoring and management tasks associated with the personalcomputers and work stations have correspondingly increased in volume andcomplexity, and have become a costly and complex burden for manyorganizations and individuals. As a result, significant research anddevelopment efforts have been directed to automating, as much aspossible, monitoring and managing tasks, including data backup, securitymonitoring, software-update management, configuration management, andother such tasks. Effective automated, remote monitoring and managementof computers and work stations depends on monitoring and managementsoftware running on remove server computers as well as on robust andreliable communications systems that interconnect these remote servercomputers with the personal computers and work stations, referred tocollectively, in the following discussion, as client computers.Manufacturers and developers of monitoring and management software,monitoring-and-management-service providers, and the many differenttypes of organizations and individuals have all recognized the need forincreasingly robust and reliable client/server control protocols forinterconnecting client computers to remote monitoring-and-managementserver computers.

SUMMARY OF THE INVENTION

In various embodiments of the present invention, tieredcommand-propagation methods are employed within client computers toensure that monitoring-and-management-related commands are reliablypropagated from server computers to client computers. When possible,command propagation is initiated by server computers through anotification process. When the notification process is inoperable,client computers poll one or more monitoring-and-management servercomputer for commands. When a failed or interrupted notification processis subsequently restored to operability, client computers automaticallydiscontinue command polling and resume relying on server notificationfor command propagation.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-D illustrate the client-computer monitoring and managementenvironment in which the adaptive control protocols that representembodiments of the present invention find use.

FIG. 2 is a control-flow diagram that illustrates client polling.

FIG. 3 illustrates a second command-propagation method.

FIGS. 4A-B compare the two command-propagation methods described abovewith reference to FIGS. 2 and 3, respectively.

FIG. 5 is a state-transition diagram that represents the client side ofa family of adaptive control protocols that represent embodiments of thepresent invention.

FIG. 6 is a state-transition diagram that represents the server side ofa family of adaptive control protocols that represent embodiments of thepresent invention.

FIGS. 7-8 are control-flow diagrams that describe the client-sideadaptive control protocols that represent embodiments of the presentinvention.

FIG. 9 is a control-flow diagram for the server-side adaptive controlprotocols that represent embodiments of the present invention.

FIG. 10 illustrates one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is directed to a robust, reliable, andcost-effective adaptive protocol for interconnecting server computersrunning monitoring-and-management software with client computers thatare monitored and managed by the server computers. The control protocolsare adaptive, in that protocol characteristics are automaticallymonitored and adapted to changing conditions. The control protocols arerobust and reliable in that various temporary and longer-durationfailures and problems can be tolerated by the control protocol, withoutsignificant interruption of command propagation from server computers toclient computers. The control protocols are cost effective because, inmany cases, existing, already-implemented communications components maybe used in both server and client computers to implement the controlprotocol. In addition, use of existing communications componentssignificantly contributes to robustness and reliability, since many ofthese components are widely used in a variety of different applications,and are therefore extremely well tested and constantly updated.

FIGS. 1A-D illustrate the client-computer monitoring and managementenvironment in which the adaptive control protocols that representembodiments of the present invention find use. FIGS. 1A-D all employ thesame illustration conventions, described below with reference to FIG.1A. For simplicity, a single-server computer 102 is shown, together witha number of client computers. In more complex environments, multipleserver computers, including multi-processor server computers, distributemonitoring and managing tasks among themselves, storing and retrievingdata from remote disk arrays, in order to monitor and manage largenumbers of client computers. However, for the purposes of the presentdiscussion, description of a single-server environment is sufficient todescribe the family of adaptive control protocols that representembodiments of the present invention.

The server computer 102 includes client-management routines 104 thattogether provide a client-management interface to administrators, aclient-computer interface through adaptive control protocols thatrepresent embodiments of the present invention, and that may employvarious internal interfaces to additional components of theclient-computer monitoring-and-management system, as well as to anoperating system, database management systems, file systems, and othersuch components. The client-management routines rely on stored policies106 and other stored information that characterize particularizedmonitoring and management tasks that need to be performed for individualclient computers. These policies and other information may be cached inmemory and stored internally or remotely on mass-storage devices. Theclient-management routines 104 also rely on a communications component108 through which data and commands can be transferred between theserver computer 102 and the number of client computers 104-112. Theserver computer 102, as discussed above, may be connected to any of avariety of different types of local or remote data-storage systems,represented in FIG. 1A by a disk-like component 110.

FIG. 1B illustrates an interface between the client-management routinesof the server computer and external administrators. As discussed above,the client-management routines 104 implement an administration interfaceto allow administrators to set, update, manage, and delete managementpolicies 106. Administrators may be human administrators that interactwith the client-management routines through a graphical user interfacedisplayed on a local or remote display device, and may also be automatedadministrator proxies that run locally or remotely on behalf of externaladministration services and remote human administrators. Because thepolicies and other information that characterizes and controls provisionof monitoring-and-management services by the server computer to variousclient computers are stored on the server computer, themonitoring-and-management services may be significantly more robust andreliable than systems in which such policies and information are storedon client computers. The policies and other control information can bereliably stored on multiple local and remote mass-storage devices by theserver computer to achieve high levels of fault tolerance andavailability that cannot be achieved, or that can be achieved only atlarge expense, on client computers. Centralized storing of thesepolicies and other information also provides more efficient, centralizedcontrol, management, and updating of the policies and other information.

FIGS. 1C-D illustrate a typical monitoring-and-management serviceprovided by the service computer to client computers. In FIG. 1C, theclient-management routines 104 continuously access and monitor thestored policies and other information to determine when specificmanagement tasks may need to be undertaken. For example, in FIG. 1 C,the client-management routines may discover, by accessing the policiesand other information, that a particular client computer 107 should bebacked up at the current time. The client-management routines 104therefore send a backup notification 110 to the client computer 107. Asshown in FIG. 1D, the client computer 107 may then undertake, through anexchange of messages and data, to collect and forward 120 the data thatneeds to be backed up to the server computer 102 for processing andstorage on one or more storage devices 116 available to the servercomputer 102.

Because policies and other information are stored on the servercomputer, it is important that, when the client-management routines onthe server computer identify tasks and operations that need to becarried out on behalf of client computers, commands representing thesetasks and operations be propagated reliably and in timely fashion to theclient computers. However, a variety of different types of failures,both long-term and of short duration, may conspire to inhibit or preventcommand propagation. For example, client computers within organizationsmay become isolated from the server computer due to installation offirewalls, security software, or additional up-stream computingfacilities within the organization. In such cases, a givencommunications link that previously interconnected the server computerand the client computer may be interrupted or made inoperable. Inaddition, client computers may intermittently be taken off line, shutdown for maintenance purposes, or otherwise become unavailable forcommunicating with the server computer. It is important for automatedmonitoring-and-management services that such communications and computerfailures be recognized and automatically overcome, so that monitoringand management services can continue to be provided by the servercomputer to the client computers in a timely fashion. For example, werea client computer to lose a communications link by which the clientcomputer communicates with the server computer, and were the clientcomputer to therefore fail to be backed up, then a subsequentmass-storage-device failure on the client computer may prove to becatastrophic. For this reasons, the adaptive control protocols thatrepresent embodiments of the present invention are able to recognizesuch failures and to employ alternative communications methods in orderto continue provision of monitoring-and-management services by theserver computer to the client computers. Moreover, failure detection andadaptive response is generally automatic, and does not require humanintervention. In various embodiments of the present invention, theserver computer may maintain an internal command cache to ensure thatcommands intended for propagation to a client computer are not lost dueto communications failures or client-computer failures. Moreover,embodiments of the present invention may separate command propagationfrom data transfer, so that command propagation may continue even whendata-transfer facilities are interrupted or fail, and vice versa.Separation of command-propagation communications from data-transfercommunications may also facilitate communications load balancing onclient computers. Finally, the adaptive control protocols that representembodiments of the present invention are generally implemented usingexisting communications components and services that are used for otherpurposes and that are widely available from software and hardwarevendors. By using existing components, both the reliability androbustness of the adaptive control protocols are increased, and the costmay be significantly decreased in comparison to de novo implementation.

There are two main models for command propagation from the servercomputer to a client computer. A first model involves client polling ofthe server computer. FIG. 2 is a control-flow diagram that illustratesclient polling. FIG. 2 illustrates one particular type, or style, ofclient polling, although many different client-polling techniques may beused. First, in step 202, an interval timer is set to generate an alarm,or timer-expiration event, at a future point in time that represents anext polling time interval. Then, in the continuous loop of steps204-210, the client waits for the interval-timer interrupt, in step 205,and, upon receiving the timer interrupt or timer-expiration event,restores a communications context, in step 206, sends a request forcommand information to the server via the communications context, instep 207. A communications context is generally a process or threadthat, along with underlying operating-system routines and hardware,allows for data to be transferred between a client computer and a remotecomputer. In step 208, the client waits for a response from the serverand, when the response is received, carries out tasks associated withany commands included in the response in step 209. In step 210, theinterval timer is reset, and the continuous loop iterates again. Ofcourse, the client computer generally concurrently carries out manydifferent tasks and executes many different processes while waiting fora next interval-timer interrupt. Moreover, the client computer carriesout additional tasks and executes different processes during the timethat the client computer waits for a response, in step 208, from theserver computer.

While client polling is effective in polling commands from the server,client polling generally involves significant overhead on the clientcomputer. In particular, restoration of a communications context, instep 206, may involve significant data-transfer overhead. Moreover, thepolling process is continuous, so that the overhead is continuouslyrepeated, at regular intervals, even when no commands are available fromthe server. In many monitoring-and-management services, commands may bequite infrequently made available. For example, backup commands may beissued on a daily or even weekly basis. Therefore, client polling mayrepresent a significant computational overhead in view of infrequentcommand propagation.

FIG. 3 illustrates a second command-propagation method. This secondcommand-propagation method involves notification, by the servercomputer, when commands become available on the server computer forpropagation to client computers. In this case, the client receives anotification event, in step 302, and based on the event, carries out anyadditional tasks associated with the event 304. For example, in manyembodiments of the present invention, the client may then launch aprocess that fetches the command from the server computer and carriesout processing tasks associated with the command. In this secondcommand-propagation method, the client computer does not expendsignificant computation overhead monitoring the server computer forcommand availability. Instead, in general, an existingevent-notification service, used for other purposes on the clientcomputer, may be employed by the server computer to asynchronouslynotify the client computer upon availability of commands on the servercomputer.

FIGS. 4A-B compare the two command-propagation methods described abovewith reference to FIGS. 2 and 3, respectively. As shown in FIG. 4A, overan interval of time represented by a horizontal time axis 402, a clientcomputer needs to repeatedly poll the server computer, where eachrequest sent by the client computer to the server computer isrepresented, in FIG. 4A, by a vertical arrow, such as vertical arrow404. Eventually, at some subsequent point in time 406, a request for acommand through a polling operation 408 may solicit a command response410 from the server computer that results in the client computerexecuting tasks associated with the command 412. By contrast, as shownin FIG. 4B, using the notification-based command-propagation method, theclient computer essentially does nothing until the point in time 406when a command becomes available from the server, communicated to theclient computer by an asynchronous notification 414. Upon reception ofthe notification, the client computer undertakes those tasks 416 neededto fetch and carry out the command.

Many existing control protocols rely on only one of the twocommand-propagation methods, discussed above, for propagating commandsbetween the server computer and the client computers. Failure of thenotification process may be deleterious or fatal to continued commandpropagation, when only a notification method is employed. While theclient-polling method may provide better reliability, with regard tocertain types of failures and degradations, the client-polling processcan be computationally expensive, as discussed above.

In order to enhance reliability and robustness, achieve greater costeffectiveness, and minimize computational overhead, embodiments of thepresent invention employ both the notification method and theclient-polling method for command propagation, and do so in a way tominimize the computational overhead associated with client polling.Moreover, different communications facilities are used for notificationand polling, with the redundancy contributing to overall reliability.

FIG. 5 is a state-transition diagram that represents the client side ofa family of adaptive control protocols that represent embodiments of thepresent invention. In FIG. 5, and in FIG. 6, discussed below, each stateis represented by a labeled disk, such as labeled disk 502, and statetransitions are shown as arrows. Following power-up 502, the client-sideadaptive control protocol (“ACP”) enters the notification state 504 thatrepresents notification-based command propagation. At very longintervals, the client-side ACP transitions to a sync state 506 in whichthe client-side ACP sends a synchronization request 508 to the server.When a response to the synchronization request is received by the client510, the client-side ACP reverts to the notification state 504. When aresponse is not received from the server 512, then the client-side ACPtransitions to the polling state 514. The polling state representsclient-polling-based command propagation. From the polling state, theclient-side ACP infrequently transitions 516 back to the synchronizationstate 506, in which the client-side ACP again sends a synchronizationrequest to the server computer. Thus, when the notification-basedcommand-propagation method is operational, as indicated by serverresponses to synchronization requests, the client-side ACP inhabits thenotification state 504.

The client-side ACP frequently transitions from the polling state 514 tothe next-polling-request state 518. In this state, the client-side ACPsends a polling request to the server. When indication of an availablecommand is received in response to a polling request, the client-sideACP transitions to a command-processing state 520. Otherwise, thecommand-side ACP transitions back to the polling state 514. In thecommand-processing state 520, the client may carry out a variety of dataexchanges with the server, including initially fetching the availablecommand from the server. In the command-processing state 520, theclient-side ACP also continues to poll, by a different mechanism, theserver for commands, as represented by the internal poll state 522. Inthis case, reception of an indication of the availability of anadditional command as well as an indication of no command beingavailable both cause return to the command processing state 520. Whenexecution related to command processing is finished, then theclient-side ACP transitions 524 back to the polling state 514. From thenotification state 504, the client-side ACP transitions 526 to acommand-processing state 528 similar to command-processing state 520.The only difference in the two command-processing states is that, in thecase of command-processing state 520, command completion results intransition back to the polling state 514, while in the case ofcommand-processing state 528, command completion results in transition530 back to the notification state 504.

To summarize, in embodiments of the present invention, thenotification-based command-propagation mode is preferred but, when thenotification process is inoperable, a client-polling-based method ofcommand propagation is employed. As soon as the notification-basedmethod again becomes operable, the notification method is again employedin preference to polling. In all cases, during command processing, acommunications context is constructed by the client computer for datatransfer between the client and server during command execution. Duringthis time, the client computer uses that context forclient-polling-based command propagation, since, for the duration ofcommand processing, with a communications context already resident andfunctioning, client-polling command propagation does not representsignificant additional computation burden.

FIG. 6 is a state-transition diagram that represents the server side ofa family of adaptive control protocols that represent embodiments of thepresent invention. Following power-up 602, the server enters aclient-management state 604. When the server determines, duringmonitoring of policies and other information, that a command needs to beissued to a particular client computer, then the server-side ACPtransitions 606 to a new-command state 608, and returns to theclient-management state 604 by notifying the client of the new commandand queuing the new command in a command queue resident on the servercomputer. The server-side ACP transitions to a command-processing state610 upon receiving a command 612 from a client computer, and returns tothe client-management state 604 when command processing is completed.Command processing may involve, for example, a number of data transfersor other such activities carried out by and/or on behalf of, the clientcomputer.

It should be noted that the state-transition diagrams of FIG. 5 and FIG.6 describe states with respect to a single server/client pair. In thecase of the server computer, the server-side ACP may inhabit the commandprocessing state 610 with respect to a particular client whileinhabiting the client-management state 604 with respect to other clientcomputers. Finally, the server-side ACP may transition to a poll-requeststate 614 upon receiving a poll request 616 from a client computer, andreturns to the client-management state 604 upon returning indications ofany queued commands for the client computer to the client computer 618.

The state-transition diagrams provided in FIGS. 5 and 6 are not intendedto be sufficiently detailed to describe particular implementations of aparticular ACP that represents an embodiment of the present invention,but are instead intended to describe, at a high level, the generalmethod implemented in ACP's that represents embodiments of the presentinvention. In any particular implementation, there may be many morestates and state transitions corresponding to the detailed processes bywhich client/server communications are carried out.

FIGS. 7-8 are control-flow diagrams that describe the client-sideadaptive control protocols that represent embodiments of the presentinvention. FIG. 7 shows a client-side ACP at a high level, and FIG. 8shows a routine called from the control-flow diagram shown in FIG. 7.Referring to FIG. 7, in step 702, the client-side ACP sets asynchronization timer. Note that, in this discussion, the term “timer”refers to any of various types of services or functionalities that allowa process to wait for a period of time before undertaking sometime-related activity. Operating systems generally provide timerroutines, but many other methods for timed waits can be used. Then, inthe continuous loop of steps 704-720, the client-side ACP continuouslyreceives and executes commands from a monitoring-and-management server.In step 705, the client-side ACP waits for a next event. Note that,while waiting for the next event, the client computer generally carriesout many other tasks and executes a large number of other concurrentprocesses. If a notification event is received, as determined in step706, then the client-side ACP calls the routine “process command,” instep 707. that routine is described below with reference to FIG. 8.Otherwise, if a synchronization-timer expiration is detected, in step708, then the client-side ACP sends a synchronization request to theserver, in step 709, and, in step 710, resets the synchronization timerand sets a synchronization-response timer. Otherwise, if the event is adetection of expiration of a synchronization-response timer, asdetermined in step 711, then, in step 712, the client-side ACP sets apolling timer. Otherwise, if the event corresponds to reception of asynchronization response from the server, as determined in step 713,then, when the polling timer is set, the polling timer is disabled, instep 714. Otherwise, the event corresponds to a polling-timerexpiration, as determined in step 715, then, in step 716, theclient-side ACP sends a polling request to the server and resets thepolling timer, in step 717. Otherwise, when the server has sent, in apolling-request response, an indication that a command is available onthe server for the client, as determined in step 718, then the routine“process command” is invoked, in step 719. Otherwise, if some other typeof event has occurred, then that event is handled in step 720.

Thus, when the notification-based command propagation method isavailable, the client waits for notification of the availability of acommand on the server, and calls the routine “processCommand,” in step707, to fetch and execute the command. When notification is inoperable,as detected by expiration of a synchronization-response timer, thenclient-polling is launched by setting a polling timer, in step 712, withcommand-availability indications returned in response to pollingreceived in step 718. Whenever a synchronization-request response isreceived, then polling is disabled, in step 714.

FIG. 8 is a control-flow diagram for the routine “process commands”called in steps 707 and 719 of the control-flow diagram shown in FIG. 7.In step 802, the client computer launches a command-processing processor thread in order to fetch and process a command indicated to beavailable on the server. In step 804, the routine “process commands”disables the client-polling timer, set in step 712 of FIG. 7, when thattimer has been set. In step 806, the client-side ACP sets an internalpolling timer. In a loop comprising steps 808, 810-812, and 816-818, theclient side ACP processes the command as well as handles various ACPevents. Processing of the command, in step 808, may involve datatransfers, computation on the client, computation on the server, orcomputation both on the client and server, and many other types ofactivities. For example, execution of a backup request may involvefetching the backup request from the server by the client, marshallingthe data by the client, and sending the data to the server in a sequenceof data-transfer steps. The server receives the data transfers,processes the data-transfer messages to extract the data for back up,may compress the data or otherwise transform the data for efficientstorage, and may then store the data on a mass-storage device. Suchdetails are beyond the scope of the present discussion, and omitted bothfrom the state-transition diagrams previously discussed and from thecurrently discussed control-flow diagrams. While a command is fetchedand processed, in step 808, additional events may occur. When aninternal-polling-timer expiration is detected, in step 810, theclient-side ACP sends a request for commands to the server, in step 811,and resets the internal polling timer in step 812. When a serverresponds to a polling request from the client, made in step 811, with anindication that an additional command is available, as determined instep 816, that indication is added to a queue internal to the client, instep 817, so that that command will be subsequently processed in step808 after the currently processed command is finished. If more commandprocessing is needed, as determined in step 818, then control flows backto step 808. Otherwise, in step 820, the client-side ACP disables theinternal polling timer and re-enables the client-polling timer when thattimer was initially set when the routine “processCommands” was called.

FIG. 9 is a control-flow diagram for the server-side adaptive controlprotocols that represent embodiments of the present invention. Thiscontrol-flow diagram comprises an endless loop of steps 902-912. In step903, the server executes the client-management routines thatcontinuously monitor policies and other information and wait for events.If a request to add or update policies is received, in step 904, thenthe server undertakes policy addition, update, or other policymanagement tasks in step 905. Such requests generally arise through anadministration interface provided by the management routines. Whenmanagement routines generate an event responding to the need for acommand to be executed, as determined in step 906, then the server-sideACP sends the notification to the corresponding client computer, andqueues the command, in step 907. When the server-side ACP receives acommand request from a client computer, as determined in step 908, then,in step 909, the server-side ACP sends an indication of the command orcommands queued for the client computer to the client computer. When theserver-side ACP receives a synchronization request from a clientcomputer, as determined in step 910, then, in step 911, the servercomputer responds to the client computer with a synchronizationresponse. Other events are handled collectively in step 912.

FIG. 10 illustrates one embodiment of the present invention. Amonitoring-and-management server is represented by rectangular box 1002,and a client computer managed and monitored by the server is representedby rectangular box 1004. The client computer includes aWindows-Management-Instrumentation (“WMI”) provider 1006, a nativeclient process 1008, and intermittently, a Java-Virtual-Machine (“JVM”)thread 1010 that is invoked for processing one or more specificcommands. The server 1002 implements the WMI service, as well as asimple-object-access protocol (“SOAP”) service 1012. WMI services andproviders are standard components, implemented by Microsoft, of manyserver and client computers. WMI was developed to facilitate exchange ofmanagement information between computers. WMI comes with a standard setof automation interfaces, .NET management interfaces, DOM/DCOMprogramming interfaces, remoting capabilities, query support, eventnotification functions, a code template generator, and many otherfeatures. WMI is therefore an existing communications component thatprovides mechanism for a server to notify a client asynchronously of theavailability of commands for the client. A WMI provider is generallyavailable on client computers and is implemented as a dynamically linkedlibrary. The presence of a WMI provider does not constitutecomputational overhead for the client computer. Thus, thenotification-based portion of the ACPs that represent embodiments of thepresent invention may be implemented as WMI-facilitated eventnotification service. The native client process 1008 generallyimplements the client-side ACP. The native client process may employ theSOAP protocol for exchanging XML-based messages to a server computer.The SOAP protocol is also an existing communications component thatprovides an alternative communications path from the client to theserver computer. JVM threads, 1010, are launched on a per-command basisto process commands, and communicate with the server through the JVMsoap protocol and through a separate data-transfer path.

When the server 1002 determines that a next command needs to beprocessed by a client, the server can notify the client via the WMIevent-notification facility 1014. The WMI provider 1006 receives theevent, and notifies the native client process 1008 through the NET cornand remoting facilities 1016. The native client process 1008 can theninvoke a JVM thread 1010 through the Java Native Interface 1018 to fetchthe command from the server, using the JVM SOAP protocol 1020, and canexecute the command using an alternative data-transfer path 1022, suchas various file transfer protocols that allow data to be transferredthrough the Internet. When notification through the WMIevent-notification facility 1014 is unavailable, due to construction ofa firewall or other such event, the native client process can poll forcommands using a native SOAP-based polling 1024. In addition, the nativeclient process can use native SOAP polling to send synchronizationrequests 1026 to the server, which responds via the WMI facility 1028.

Although the present invention has been described in terms of particularembodiments, it is not intended that the invention be limited to theseembodiments. Modifications within the spirit of the invention will beapparent to those skilled in the art. For example, the client/serverACPs that represent embodiments of the present invention may beimplemented using any number of existing communications components, inaddition to, or instead of, those discussed with reference to FIG. 10,and can be implemented de novo, when needed. These communicationscomponents can be implemented in any number of different programminglanguages using different code modularization, data structures, controlstructures, variables, and other such programming parameters. Thecommunications between the client and server may be carried out over anynumber of different underlying communications services hardware andlower-level software components within the client and server computers.Polling intervals, synchronization-request intervals, and other suchparameters may be adjusted to achieve desired adaptation responses withdesired levels of computational overhead. The client/server ACPs thatrepresent embodiments of the present invention are easily extended todistributed monitoring-and-management systems involving multiple servercomputers, including multi-processor server computers, and other complexenvironments.

The foregoing description, for purposes of explanation, used specificnomenclature to provide a thorough understanding of the invention.However, it will be apparent to one skilled in the art that the specificdetails are not required in order to practice the invention. Theforegoing descriptions of specific embodiments of the present inventionare presented for purpose of illustration and description. They are notintended to be exhaustive or to limit the invention to the precise formsdisclosed. Many modifications and variations are possible in view of theabove teachings. The embodiments are shown and described in order tobest explain the principles of the invention and its practicalapplications, to thereby enable others skilled in the art to bestutilize the invention and various embodiments with various modificationsas are suited to the particular use contemplated. It is intended thatthe scope of the invention be defined by the following claims and theirequivalents:

1. A client-computer monitoring-and-management system comprising: amonitoring-and-management server computer that generates commands forpropagation to a client computer; a client computer that receivescommands from the monitoring-and-management server, each commandrepresenting a management task that the monitoring-and-management serverhas identified as needing to be executed by the client computer; and anadaptive client/server control protocol that when a server-to-clientasynchronous notification facility is operational, asynchronouslydelivers command-availability notification from themonitoring-and-management server to the client computer, and when theserver-to-client asynchronous notification facility is not operational,provides for polling of the monitoring-and-management server computer bythe client computer in order for the client computer to detect commandsgenerated by the monitoring-and-management server computer by receivingcommand notification through monitoring-and-management server responsesto poll requests sent by the client computer.
 2. The client-computermonitoring-and-management system of claim 1 wherein themonitoring-and-management server monitors policies and managementinformation stored on, or accessible to, the monitoring-and-managementsystem in order to determine when to generate a command, and queuesgenerated commands to a command queue in addition to asynchronouslydelivering a command-availability notification to the client computer.3. The client-computer monitoring-and-management system of claim 2wherein, upon receiving a poll request from the client computer, themonitoring-and-management server computer returns a response to the pollrequest containing an indication of the availability of commandspreviously queued by the monitoring-and-management server for the clientcomputer.
 4. The client-computer monitoring-and-management system ofclaim 1 further comprising determining, by the adaptive client/servercontrol protocol, whether or not the notification facility isoperational by: periodically sending a synchronization request from theclient computer to the monitoring-and-management server computer; when aresponse to the synchronization request is received by the clientcomputer through the notification facility, determining the notificationfacility to be operational; and when a response to the synchronizationrequest is not received by the client computer through the notificationfacility, determining the notification facility to be not operational.5. The client-computer monitoring-and-management system of claim 1wherein the client computer polls the monitoring-and-management servercomputer through a second communications facility distinct from thenotification facility.
 6. The client-computer monitoring-and-managementsystem of claim 5 further comprising: upon receiving, by the clientcomputer, notification of command availability or receiving apoll-request response indicating command availability, launching by theclient computer of a command-processing thread; requesting the commandfrom the monitoring-and-management server by the command-processingthread; receiving the command by the command-processing thread from themonitoring-and-management server; and executing the received command bythe command-processing thread.
 7. The client-computermonitoring-and-management system of claim 6 wherein, once launched bythe client computer, the command-processing thread polls themonitoring-and-management server for additional commands through a thirdcommunications facility distinct from the second communications facilityand from the notification facility.
 8. The client-computermonitoring-and-management system of claim 1 wherein a windows managementinstrumentation service, on the monitoring-and-management servercomputer, and a windows management instrumentation provider, on theclient computer, together provide the notification facility; and whereinthe client computer polls the monitoring-and-management server computerthrough a simple object access protocol.
 9. The client-computermonitoring-and-management system of claim 1 wherein upon receiving, bythe client computer, notification of command availability or receiving apoll-request response indicating command availability, the clientcomputer launches a Java virtual machine thread to process the command.10. The client-computer monitoring-and-management system of claim 1wherein multiple monitoring-and-management servers cooperate to monitorand manage multiple client computers.
 11. A method for propagatingcommands from a monitoring-and-management server computer to a clientcomputer, the method comprising: generating commands by themonitoring-and-management server computer; queuing generated commands bythe monitoring-and-management server computer in a command queue;sending an asynchronous notification by the monitoring-and-managementserver computer to the client computer when a command is generated; whena server-to-client asynchronous notification facility is operational,receiving the asynchronous notification from themonitoring-and-management server by the client computer; and when theserver-to-client asynchronous notification facility is not operational,polling, by the client computer, the monitoring-and-management servercomputer to detect commands generated by the monitoring-and-managementserver computer.
 12. The method of claim 11 wherein themonitoring-and-management server monitors policies and managementinformation stored on, or accessible to, the monitoring-and-managementsystem in order to determine when to generate a command.
 13. The methodof claim 11 wherein polling, by the client computer further comprises:periodically sending poll requests to the monitoring-and-managementserver computer; and receiving poll-request responses from themonitoring-and-management server computer,
 14. The method of claim 13wherein, upon receiving a poll request from the client computer, themonitoring-and-management server computer returns a response to the pollrequest containing an indication of the availability of commandspreviously queued by the monitoring-and-management server for the clientcomputer.
 15. The method of claim 11 further comprising determining, bythe adaptive client/server control protocol, whether or not thenotification facility is operational by: periodically sending asynchronization request from the client computer to themonitoring-and-management server computer; when a response to thesynchronization request is received by the client computer through thenotification facility, determining the notification facility to beoperational; and when a response to the synchronization request is notreceived by the client computer through the notification facility,determining the notification facility to be not operational.
 16. Themethod of claim 11 wherein the client computer polls themonitoring-and-management server computer through a secondcommunications facility distinct from the notification facility.
 17. Themethod of claim 16 further comprising: upon receiving notification ofcommand availability or receiving a poll-request response indicatingcommand availability, the client computer, launching by the clientcomputer of a command-processing thread; requesting the command from themonitoring-and-management server by the command-processing thread;receiving the command by the command-processing thread from themonitoring-and-management server; and executing the received command bythe command-processing thread.
 18. The method of claim 17 wherein, oncelaunched by the client computer, the command-processing thread polls themonitoring-and-management server for additional commands through a thirdcommunications facility distinct from the second communications facilityand from the notification facility.
 19. The method of claim 11 wherein awindows management instrumentation service, on themonitoring-and-management server computer, and a windows managementinstrumentation provider, on the client computer, together provide thenotification facility; and wherein the client computer polls themonitoring-and-management server computer through a simple object accessprotocol.
 20. The method of claim 11 wherein upon receiving, by theclient computer, notification of command availability or receiving apoll-request response indicating command availability, the clientcomputer launches a Java virtual machine thread to process the command.